A Post by Michael B. Spring
The research on collaborative authoring (August 10,2008)
I was recently asked what happened to the research
on collaborative authoring that seemed to have died
out around 2000. The question came to me because of the work I and
my PhD students -- notably Bordin Sapsomboon, Wasu Chapanon and
Marut Buranarach, had done on a system called CASCADE -- Computer Augmented
Support fro Collaborative Authoring and Document Editing.
I was reminded of a literature search this past summer on
web-based group decision support systems undertaken by a
beginning PhD student who was visiting for the summer.
Much of the significant literature seemed to have been
developed in the early to mid nineties. Since that time,
there has been little new work. It is all to easy to simply blame the
web. It does indeed seem that much of what students want to do today
is simply build little toy systems that provide one small aspect
of a solution to problems studied more seriously in the pre-web
years. As with most situations, the question would appear to have
a more complex answer.
What happened to research on collaborative authoring? Over the years
personal reflections have included several reasons why more is not
being done.
- Maybe we were fooling ourselves. The research that many
of us were doing in the mid to late nineties looked to "augment"
the "collaborative authoring" process and make it better.
My own system, CASCADE was designed to be both a functional system
and a testbed for research on the complex phenomenon.
At the heart of our work was the assumption that
there are people who do, or want to, write collaboratively.
Our prototype documents were national and international
standards. When all was said and done, despite
committees of hundreds, the writing was really still done
by only one or two people with lots of comments from others.
Indeed, the same seems to hold true in the academic world.
While there may be many authors on the proposal or the paper,
the vast majority of the work is done by one person. So,
observation one is that "collaborative authoring" may be a
pipe dream. Generally speaking individuals write, and
depending on their situation, make use of comments
and feedback from other people. Word with commenting and change
tracking facilities may be enough.
- The demands of group authoring. In order to accomplish
many of the goals of collaborative authoring, such
as fine grain locks and style consistency, we needed editors
that were somewhat more structured than people were used to --
e.g. we were using xml as the basis of our locking system.
User feedback made clear that any
editor was great so long as it was exactly like Word, or
whatever editor the user was familiar with. At the time,
and to a lesser extent still today, Word couldn't do what
we needed to do, so we built our own more structured editors.
It was an uphill struggle to get end users to accept a more
structured approach. Beyond this, even if we could have
mimicked Word, we still would have imposed more structure.
Corporate documents are not like personal documents,
but people don't like to hear that. (As a plug for my own
work, I tell my students that the best way to classify
documents is as personal, group, corporate, enterprise,
or archival. Each is increasingly more restricted
and standards bound. It may not be important how you
write a personal love note, but documents that flow
across enterprises have to be understood by all who
encounter them. The penultimate demands for structure
occur when a document -- a birth certificate or an
academic record has to survive time and space for uses
that may not yet be defined -- a requirement for archival
documents. Our reality suggested more structure was
needed. The user demand was to be able to do whatever
they wanted.
- Microsoft does what people want. Word got a lot
better at supporting informal collaboration.
The emergence and refinement
of the track changes and SharePoint linkages
for word are
a real boon. As refinements to the de facto standard --
Word got better, the demand for specialized software
diminished. Even if Word is still less than what we were
trying to do, it was close enough.
- We all fell in love with the Web. I was actively
engaged in collaborative authoring research when the
web appeared. I was well aware of Berners-Lee's vision
of the WWW as an interactive system. When WEBDAV
extensions came along, we moved a little closer to
authoring as well as dissemination, but it clearly was
not enough. Given a few more years we got blogs and
wikis. While a wiki does only a tiny fraction of what
we wanted to do, for the class of people who like a little
collaboration with minimal structure, it was more than
enough. So the Web took the low end of the market out. In
addition the people who would be the early adopters --
the young people -- think wikis are great and see no
reason for real collaborative tools. With time, the
growing array of content managment systems will fill
much of the gap. It still turns my stomach when
I ask PhD students to assess the capabilities of
the best wikis. They seldom if ever come up with
the dozen or so things they don't do that we were
working on in the late 90's. For today's generation
concentrated analysis of what would make for great
collabortative systems is weak.
- The rise of the firewalls. Related to the web,
our software was connection oriented client server
software. We has state information and knew who
was working on what and when. This required a concurrent
connection oriented client server system. The protocol
ran on a port of its own -- i.e. it did not piggy back
on a well known protocol. This was common for client
server systems design in the pre web era.
As our project moved forward,
so did corporate firewalls and between 1996 and 2000
they were being locked down tightly to prevent the
growing cadre of hackers trying to penetrate corporate
resources. Nothing could get out from individual desktops unless
it was directed to port 80. (At one point I wrote a
tunneling proxy program that maintained state, but
worked through idempotent http connections to
satisfy the network Nazi's.) The situation has
improved a little since then, but not much. The
rich array of distributed software using
sophisticated client server protocols were sent
into oblivion as firewalls emerged and demanded
that anything that was to be done would have to be
done through the web protocol -- a stateless
request/response protocol.
- Research on the social periphery. Some of the most
exciting work we were doing was related to adaptation and
the social periphery. That is, in face-to-face
collaboration you begin to work as a seamless team and
you get to read your teammates eyes and perspiration
levels -- you can sense who is with you and who is against
you. We were working to infer that social periphery based
on micro actions and make it visible to team members.
As you might guess, trying to make
explicit what the best team leaders have been doing for
years was not exactly something people endorsed. Too much
like big brother. This was the most exciting research, and
the most controversial.
- The mistaken belief that the goal is efficiency.
My work was based on the fact that it takes about 10
years and 10 million dollars to produce a national or
international standard in IT. We were going to reduce
that to 5 years and 5 million dollars, and I am still
convinced we could. The big savings came in supporting
synchronous and asynchronous collaboration on the document
via the computer rather than traveling to cities like Paris,
London, Tokyo, San Francisco, etc, three times a year to meet
and iron out details. We also eliminated all the formal
paper ballots and mailings. Well guess what. The senior
engineers really didn't want to be that efficient. They
were at a point in their career where regular travel to
global cities for meetings with old friends -- look at the
rosters of standards committees -- was a boon not an
obstacle. Further, the SDO secretariats at the time
were made up of older engineers and the notion of
substituting computer based systems for the paper systems
that justified their large staff and corporate existence
was not quite what they had in mind. ANSI, ISO, and the
ITU also had regulations that were paper based in actual
specification. Much of this has now changed with the
relentless pressure to adopt technology into work processes.
While IT standardization is the world I am most familiar
with, if you look at the FDA requirements for new drug
applications, or FAA requirements for plane documentation,
a lot of them during that period were still dependent on
paper trails for auditing.